The objectives of the Requirements Management phase are:

• To define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases

Approach

General

As indicated by the "Requirements Management" circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process.

It is important to note that the Requirements Management circle denotes, not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases.

The ability to deal with changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change - the "grey area" between what stakeholders aspire to and what can be specified and engineered as a solution. Architecture requirements are therefore invariably subject to change in practice. Moreover, architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.), and which can produce changes in requirements in an unforeseen manner.

Note also that the requirements management process itself does not dispose of, address, or prioritize any requirements; this is done within the relevant phase of the ADM. It is merely the process for managing requirements throughout the overall ADM.

Resources

The world of requirements engineering is rich with emerging recommendations and processes for requirements management. TOGAF does not mandate or recommend any specific process or tool; it simply states what an effective requirements management process should achieve (i.e., the "requirements for requirements", if you like).

Business Scenarios

One effective technique that is described in TOGAF itself is business scenarios, which are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios are described in detail in Part III, Business Scenarios .

Volere Requirements Specification Template

Architecture requirements is very much a niche area within the overall requirements field. One useful resource is the Volere Requirements Specification Template, available from Volere¹ (refer to www.volere.co.uk/template.htm). While not designed with architecture requirements in mind, this is a very useful requirements template, which is freely available and may be modified or copied (for internal use, provided the copyright is appropriately acknowledged).

One interesting item in this template is the "waiting room", which is a hold-all for requirements in waiting. There are often requirements identified which, as a result of the prioritization activity that forms part of the requirements management process (see below), are designated as beyond the planned scope, or the time available, for the current iteration of the architecture. The waiting room is a repository of future requirements. Having the ability to store such requirements helps avoid the perception that they are simply being discarded, while at the same time helping to manage expectations about what will be delivered.

Requirements Tools

There is a large, and increasing, number of Commercial Off-The-Shelf (COTS) tools available for the support of requirements management, albeit not necessarily designed for architecture requirements. The Volere web site has a very useful list of leading requirements tools (see www.volere.co.uk/tools.htm).